Computer users in both the business and home environment have become accustomed to using a computer with a graphical operating system. For example, many users operate computers having a Microsoft Corporation “WINDOWS” operating system thereon. Certain components of these graphical operating systems are known as “controls.” For example, a control may be an “OK” button, which is generally a rectangular button with “OK” written in it. By moving the cursor over the button and clicking on the mouse, a known operation will begin that is associated with the control. Many other controls exist, with examples including scroll bars, dialog boxes and sliders. Beyond controls, the graphical operating systems also draw, or render, other graphical components as needed on the display of the computer, such as the frame, the minimize box and the close box.
There are two general kinds of controls in WINDOWS: standard and custom. Standard controls are provided by the operating system. The code to create, draw and operate standard controls is contained in the common control library (DLL), a part of WINDOWS. Custom controls are all other controls. Custom controls may be created by the manufacturer of the operating system or by third parties. The code for custom controls is contained in a corresponding separate library (DLL) or within an application.
Currently, when a graphical user interface component, such as a control, is used by an application, the application requests that an instance of the component be created. Following this, the operating system transmits a generic message to the component, instructing the component to render itself. The application plays a role in routing the message from the main window to the targeted control, but the control code performs the drawing. The application uses application programming interfaces (API's) to create and interact with the control. An API serves as a software interface to be used by other programs, much as the keypad serves as an interface to a calculator. An API is a fundamental concept of high-level programming. In high-level programming, a program often does not execute tasks by itself. Instead, the program asks some other program to execute these tasks. For example, programs frequently delegate various tasks to the underlying operating system. Continuing with the above example, an application delegates the rendering of a control to the control's code.
In the prior art environment, when a generic rendering message is received by a control to draw itself, the control will draw itself using its own drawing software code. In this prior art environment, the control knows what it is supposed to look like, how it is supposed to behave, and can effectuate such a display on the user interface of the computer. Thus, the application may delegate all aspects of visual rendering to the controls, avoiding the need to contain software code to support the visual rendering of the control within the host application itself.
By utilizing the standard controls defined and rendered by the operating system, all controls will have the same appearance, regardless of the application. Users of graphical operating systems can change only a limited number of characteristics of the controls. In the “WINDOWS” operating system, a user can change the color scheme used to display the various controls and components on the monitor. The user can also select a small set of fonts to be used by the controls and components. Thus, the colors, fonts and a limited set of sizes of the controls and components may be changed. However, the basic appearance of the controls and components is dictated by the rendering software code within the control library containing the particular graphical component or control. In the prior art environment, to change the appearance of the controls or graphical components, the rendering software code must be altered. For example, if it is desired to change the appearance of the “OK” button, the rendering software code within the operating system DLL file containing the button control must be altered and the DLL file reconstructed at the binary level. If it were desired to render the button as an oval, rather than as the traditional rectangle, the software code would have to be changed accordingly. Such an approach makes it difficult, if not impossible, for a computer user and for software manufacturers, to easily alter the appearance of the controls and graphical components.
In order to enhance the user experience of the computer, it would be desirable for the user to have the ability to change the overall “look and feel” of the graphical display by changing the overall visual appearance or “theme” of the various graphical components. In other words, it would be desirable if the user could change not only the color and font of the graphical components appearing on the monitor, but to change the appearance of those graphical components as well. For example, it would be desirable to be able to alter and direct the layout of the parts of a control, and to define the shape of a control or its parts. It would also be desirable to control all aspects of how a control or its parts are drawn. Because the controls and graphical components existing within the DLL file in the prior art environment are “hard coded” with their own rendering software code, it is difficult and cumbersome to change the appearance of all of the controls and components. To do so would require recoding each of the controls to achieve the desired appearance. If multiple visual styles were required, they would each have to be predefined and each “hard coded” into every control. Moreover, the controls must also be recoded if a different rendering technology is to be used. For example, if the controls are rendered using a bitmap and it is desired to utilize a vector-based renderer, each control must be altered.
Certain prior art approaches exist that attempt to address the above situation. However, these solutions do not allow all of the controls and graphical components of the entire system to be changed. Instead, the prior art approaches address only limited portions of the set of displayed components. This allows the appearance of some controls and graphical components to be altered, leaving the remainder unaltered. Such an approach leaves an appearance that is not as coordinated as may be desired.
The prior art approaches are further limited by the techniques they employ to implement control of the appearance characteristics of visual elements of the graphical user interface. Prior art appearance modifiers operate by intercepting the generic rendering signals transmitted to the control, and, using low-level operating system graphical APIs, substitute their own rendering code for that of the control. However, only a portion of the visual elements in the graphical user interface is interceptible. Because the prior art approaches depend exclusively on the interception of operating system signals, not only are they themselves incapable of controlling the appearance of visual elements that do not function according to this protocol, they are incapable of providing a standard means for the author of the visual element to modify the rendering code to accommodate external control.
Similarly, prior art approaches for rendering non-client windows components, such as window frames and the minimize box, have shortcomings. The prior art approach requires the user to buy a separate software package in order to support theming of these components. The prior art approaches are incomplete because they allow only a fixed subset of controls to be themable. Furthermore, their implementation architecture relies solely on interception of standard window messages without any control or USER32 knowledge of the theme drawing.
In the traditional operating system, non-client window components have been rendered by a default windows procedure in Windows Kernel Mode in response to a complex set of Windows messages and API calls. It would be impractical to put all the variations of themes into the single default windows procedure. Adding theme properties to default windows procedure would require more complicated code, complete recompilation of the code, and rigorous testing to determine if the code update functions properly and doesn't break any existing applications.
Further, it is not possible to intercept all relevant signals transmitted by the operating system to a control in the course of rendering. Still further, in neither the traditional operating system nor the theming methods of separate software packages is it always possible to reproduce complex visual behavior implemented by a control, such as animated sequences. Thus, the prior art approaches, including operating system approaches and approaches taken by separate software packages, are prone to functional incompatibilities, visual flaws, and performance problems.
Moreover, the prior art techniques are limited in the manner in which software developers can design controls to accommodate versatility in visual appearance. Using traditional “Ownerdraw” and “Customdraw” routines, application developers have been able to render controls with only a limited set of options. The prior art approaches do not involve an architecture that allows a control author the flexibility to design a control that is “theme aware.” Control authors are therefore not allowed the freedom needed in authoring controls to create controls that can be easily and cleanly visually altered.
Furthermore, a system that provides theme aware controls should accommodate both legacy applications and new applications that are capable of working with theme aware controls. Legacy applications have been developed and tested to work with the traditional controls that are not theme aware. New applications have been developed and tested to work with theme aware controls. A theme aware architecture must allow for both types of applications to operate on the same computer system.
For example, if a system that offers themes requires all the applications to use the theming controls even if they haven't been tested with the new controls, the application controls will not be rendered as the application developer expects. Therefore, the controls may appear inconsistent with the application's look or will be in the wrong place with respect to the application or may stop functioning altogether. Application writers should be able to control whether their applications use the new themed controls or continue using the traditional controls.
Yet another problem is that of new applications being unable to operate on traditional systems that are not theme aware. New applications will be developed and tested for new systems that provide themes. When these new applications are loaded onto old systems that are not theme aware, not only will the applications' controls not be themed, but also in many cases, the applications will fail. Therefore, there is not a way for theme aware applications to operate on non-theme aware systems.